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Foreword 



This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN) and originally published as ETSI TS 183 054 []. 
It was transferred to the 3rd Generation Partnership Project (3GPP) in December 2007. The contents of the present 
document are subject to continuing work within the TSG and may change following formal TSG approval. Should the 
TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of 
release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three Protocol Description of the Closed User Group (CUG) service, based on 
stage one and two of the ISDN Communication diversion supplementary services. It provides the protocol details in the 
IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session 
Description Protocol (SDP). 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the CUG supplementary service. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services, stage 1". 

[2] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[3] Void 

[4] Void 

[5] 3GPP TS 24.238: "Session Initiation Protocol (SIP) based user configuration; stage 3". 

[6] 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 

over the Ut interface for Manipulating Supplementary Services". 

[7] IETF RFC 5621: "Message Body HandHng in the Session Initiation Protocol (SIP)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and the following 
apply: 

basic service: bearer or teleservice. Within the scope of SIP based networks the identification of a bearer or teleservice 
can be derived from the SDP used 

Closed User Group (CUG) communication: closed user group communication is a communication which is restricted 
to a pre-defined group of users 

Closed User Group (CUG) member: user who has subscribed to the CUG service and is one of the users in the group 
formed by a particular closed user group 

CUG index: parameter used by the originating user to select a particular CUG when originating a communication 
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NOTE 1 : The index is also used by the network to indicate to the terminating user the CUG from which an 

incoming communication has originated. This index has only local significance, i.e. the index used by the 
originating user is, in general, different from the index used by the terminating user to identify the same 
CUG. 

CUG interlock code: means of identifying CUG membership within the network 

NOTE 2: At the originating side, if a CUG match exists, the CUG index identifying a CUG maps to the CUG 
interlock code for that CUG. If a CUG match exists at the terminating side the CUG interlock code 
identifying a CUG maps to the CUG index representing that CUG. CUG interlock code has relevance on 
NN level between AS. 

CUG manager: authority representing the interests of all the members of a CUG 

NOTE 3: By planning and controlling the membership and members' options, the manager can provide the overall 
CUG service expected by the members as a whole. The CUG manager need not be a CUG member and 
the concept has no signalling implications. 

incoming access: arrangement which allows a member of a closed user group to receive communications from outside 
the closed user group 

incoming communications barred within a closed user group: access restriction that prevents a closed user group 
member from receiving communications from other members of that group 

outgoing access: arrangement which allows a member of a closed user group to place communications outside the 
closed user group 

outgoing communications barred within a closed user group: access restriction that prevents a closed user group 
member from placing communications to other members of that group 

preferential CUG: user subscribing to preferential CUG nominates a CUG index which the network uses as a default 
to identify the required CUG in the absence of any CUG information in the outgoing communication request 

NOTE 4: A preferential CUG applies to a Public ID. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACR Anonymous Call Rejection 

AS Application Server 

CDIV Communication Diversion 

CONE CONFerence calling 

CUG Closed User Group 

ECT Explicit Communication Transfer 

HOLD communication HOLD 

lA Incoming Access 

ICB Incoming Communication Barring 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

MCID Malicious Communication IDentification 

OA Outgoing Access 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

PSTN Public Switched Telephone Network 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

TIP Terminating Identity Presentation 

TIR Terminating Identification Restriction 

UA User Agent 

UE User Equipment 
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URI 

XML 



Universal Resource Identifier 
extensible Markup Language 



4.1 



Closed User Group (CUG) 



Introduction 



The Closed User Group (CUG) service enables users to form groups of members, whose communication profile is 
restricted for incoming and outgoing communications. 



4.2 Description 



Members of a specific CUG can communicate among themselves but not, in general, with users outside the group. 

Specific CUG members can have additional capabilities that allow them to initiate outgoing communications to users 
outside the group, and/or to accept incoming communications from users outside the group. Specific CUG members can 
have additional restrictions that prevent outgoing communications to other members of the CUG, or prevent incoming 
communications from other members of the CUG. 

A closed user group consists of a number of members from one or more public, and/or private networks. A specific user 
may be a member of one or more CUGs. Subscription to a closed user group shall be defined for all communication 
services, or in relation to one, or to a list of communication services. 



4.3 Operational requirements 



4.3.1 Provision/withdrawal 

The CUG service shall be provided after prior arrangement with the service provider. 

As a network option based on subscription basis. The CUG service can be offered with several subscription options. 

The provisioning of a new CUG shall require a prior arrangement between the CUG Manager and the network provider. 

The provision of the CUG service to a new member and also the assignment of the various CUG service options to a 
new or existing member shall require a prior arrangement between the CUG member and the network provider in 
coordination with the CUG Manager of the affected CUG. 

The CUG Service is provisioned by the operator. 

The subscription options can be divided into three groups: 

General Subscription options. 

- Per CUG. 

- Per Public ID. 

General Subscription options: 

A user can be a member of several closed user groups as shown in table 4.3. LL Each CUG is bind to the members with 
an individual CUG Index. Each network operator shall define the maximum number of closed user groups which can be 
allocated to an individual user. 

Table 4.3.1.1: General subscription options 



Subscription options 


Value 


Closed user groups 


List of one or more closed user group indices 
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Subscription options per CUG: 

For a particular closed user group, the associated set of general subscription options can apply to one basic 
service, to a particular set of basic services, or to all basic services (see table 4.3.1.2). 

Table 4.3.1.2: Subscription options per CUG 



Subscription options 


Value 


Intra closed user group restrictions (for each 
closed user group) 


None designated 


Incoming communications barred within a 
closed user group 


Outgoing communications barred within a 
closed user group 


Applicability to basic services (for each closed 
user group) 


list of one or more basic services 


all basic services 



Subscription options per Public ID: 

The network shall provide a subscription option in order to enable the user to specify a preferential closed user 
group (see table 4.3.1.3). 

The user can request that no preferential closed user group exists, or can request that a particular one of the user's 
closed user groups (or the only one if a single closed user group applies) is used as a preferential closed user 
group. 

The closed user group indices shall be allocated by prior arrangement with the service provider. 

The choice of preferential closed user group shall be alterable only by service provider action upon request by 
the served user. 

The CUG service shall be withdrawn at the customer's request, or for administrative reasons. 
Table 4.3.1.3: Subscription options per Public ID 



subscription options 


Value 


Preferential closed user group 


None designated 


closed user group index 


Outgoing access 


allowed per communication 


allowed permanent (default) 


not allowed 


Incoming access 


allowed 


not allowed 



4.3.2 Requirements on the originating network side 

For correct interactions with other services, it is necessary for the originating network side to store, for the duration of 
the communication, details of whether a non-CUG, CUG (without outgoing access) or CUG (with outgoing access) 
communication was requested in the information sent to the destination network side. The CUG identity (if any) 
requested of the destination network side must also be retained. 

4.3.3 Requirements in tine terminating network 

For correct interactions with other supplementary services, it is necessary for the destination network side to store, for 
the duration of the communication, details of whether a non-CUG or CUG (with or without outgoing access) 
communication request was passed to the user. The CUG identity (if any) requested must also be retained. 
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4.4 Coding requirements 
4.4.1 XIVIL definition 

This subclause defines the XML Schema to be used for providing the CUG Interlock code and the 
CUGcommunicationindicator. 

The application/vnd.etsi.cug+xml MIME type used to provide CUG Interlock code, cuglndex outgoingAccessRequest 
and the CUGcommunicationindicator the XML used shall be coded as following described: 

<?xml version="LO" encoding="UTF-8"?> 

<xs:schema xmlns:xs="http://www. w3.org/2001/XMLSchema" 

xmlns="http://uri. etsi.org/ngn/params/xml/simservs/xcap" 

targetNamespace="http://uri. etsi.org/ngn/params/xml/simservs/xcap" elementFormDefault=" qualified" 

attributeFormDefault="unqualified"> <xs:annotation> 

<xs : annotation> 

<xs :documentation>XML Schema Definition for the closed user group 
parameter</xs : documentation> 
</xs : annotation> 

<! --Definition of simple types- -> 
<xs : simpleType name="twobitType" > 

<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-1] [0-1] "/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="networkIdentityType" > 
<xs : restriction base="xs .hexBinary" > 

<xs . length value="l"/> 
</xs : restriction> 
</xs : simpleType> 
<xs : simpleType name="sixteenbitType" > 

<xs : restriction base="xs : hexBinary" > 

<xs : length value="2"/> 
</xs : restriction> 
</xs : simpleType> 
<xs : simpleType name="cugIndexType"> 

<xs : restriction base="xs : integer" > 
<xs :minlnclusive value="0"/> 
<xs :maxlnclusive value="32767"/> 
</xs : restriction> 
</xs : simpleType> 

<! --Definition of complex types- -> 
<xs : complexType name= " cugRequestType " > 
<xs : sequence> 

<xs: element name=" outgoingAccessRequest" type="xs : boolean" /> 
<xs: element name=" cuglndex" type="cugIndexType"/> 
</xs : sequence> 
</xs : complexType> 

<! --Definition of document structure--> 

<xs:element name="cug" substitutionGroup="ss : absService"> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<xs:element name="cugCallOperation" type=" cugRequestType" minOccurs="0"/> 
<xs : element name="networl<:Indicator" type = "networl<:IdentityType" 
minOccurs= " " / > 

<xs : element name="cugInterlocl<:BinaryCode" type="sixteenbitType" 
minOccurs= " " / > 

<xs : element name="cugCommunicationIndicator" type="twobitType" 
minOccurs= " " / > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element> 
</xs : schema> 
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4.4.2 SIP-Messages used for CUG 

The following SIP messages are used for the invocation and control of the CUG service. 

Table 4.4.1.1 : SIP Message used for CUG 



SIP Message 


SIP URI parameter 


Used for 


INVITE request 


xml MIME CUG 




403 (Forbidden) response 




rejection because the user 
does not belongs to the CUG 
or other failure. 


603 (Decline) response 




rejection because of barring 
or CUG with call barring. 


500 (Server Internal Error) 
response 




rejection of a CUG 
communication due to 
network caused reasons e.g. 
traversing the communication 
towards an IMS not 
supporting the CUG Service. 



4.5 Signalling requirements 



4.5.0 General 

Configuration of supplementary services by the user should: 

take place over the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [6]; or 

use SIP based user configuration as described in 3GPP TS 24.238 [5]; 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 
operator are outside the scope of the present document, but are not precluded. 

The enhancements to the XML schema for use over the Ut interface are described in subclause 4.9. 

4.5.1 Activation/deactivation 

The CUG service is activated at provisioning or at the subscriber"s request by using the mechanisms specified in 
subclause 4.5.0. 

The CUG service is deactivated at withdrawal or at the subscriber" s request by using the mechanisms specified in 
subclause 4.5.0. 

4.5.1a Registration/erasure 

For registration of CUG -related information, the mechanisms specified in subclause 4.5.0 should be used. 
For erasure of CUG-related information, the mechanisms specified in subclause 4.5.0 should be used. 

4.5.1b Interrogation 

For interrogation of CUG-related information, the mechanisms specified in subclause 4.5.0 should be used. 

4.5.2 Invocation and operation 
4.5.2.1 Actions at the originating UA 

Explicit request of CUG service: 
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The originating user can explicitly request the CUG service by including in the initial INVITE request an xml 
CUGrequestType containing the preferred CUG and an outgoing access request. 

To indicate outgoing access the user shall set the value of the "outgoingAccessRequest" parameter to TRUE. 

Implicit request of CUG service: 

The originating user with CUG service can request the CUG service without including an xml CUGrequestType 
in the initial INVITE request. In this case the procedures according to 3GPP TS 24.229 [2] shall apply 

Call originating from a user without CUG service: 

It is possible for a user without CUG service to make a call to a user with CUG service. In this case the 
procedures according to 3GPP TS 24.229 [2] shall apply. 

4.5.2.2 Void 

4.5.2.3 Void 



4.5.2.4 Actions at the AS of the originating User 



Upon receipt of a request for CUG service the AS shall check its validity as shown in table 4.5.2.4.1 in conjunction with 
the access capabilities contained in the user profile. If a non-valid request is received or the checks cannot be 
performed, then the network shall reject the communication and return an appropriate indication to the originating user. 

A received INVITE request may include an xml CUGrequestType containing the preferred CUG and an outgoing 
access request. 

NOTE: In particular, a validation check is performed by verifying that both the originating and terminating 
parties belong to the CUG indicated by the interlock code. 
The data for each CUG that a user belongs to, is stored at the AS of the originating User. 

The actions at AS of the originating user at communication set-up from a user belonging to a CUG, depends on the 
result of the validation checks performed, based on whether the user belongs to one or more CUGs. 

a) CUG without outgoing access. 

If the result of the validation check indicates that the communication should be dealt with as a CUG 
communication, the interlock code of the selected CUG is obtained. The INVITE request forwarded towards the 
terminating network then includes the cuglnterlockBinaryCode, networklndicator and 
cugCommunicationlndicator. 

b) CUG communication with outgoing access. 

If the result of the validation check indicates that the communication should be dealt with as a CUG 
communication with outgoing access, the communication shall be treated as a Non-CUG communication. 

c) Non-CUG. 

If the result of the validation check indicates that the communication should be dealt with as a non-CUG 
communication, the INVITE request forwarded towards the terminating network then does not include a 
cuglnterlockBinaryCode, networklndicator and cugCommunicationlndicator 

d) Communication rejected. 

If the result of the validation check indicates that the communication is to be rejected, the communication set-up 
is not initiated. A 403 (Forbidden) response with a Reason header included shall be sent back as shown in 
table 4.5.2.4.1. 
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Table 4.5.2.4.1 : Validation check of CUG communication concerning the originating user 



Calling user 

class defined 

within the user 

profile 


Indication from originating user sent within an INVITE request | 


INVITE request for 
CUG with 
CUGIndex 


INVITE request for 

CUG with 

CUGIndex & 

outgoingAccessR 

equest 


INVITE request for 

CUG 

communication 

without CUGIndex 


INVITE request for 

CUG 

communication 

without CUGIndex 

& with 

outgoingAccessR 

equest 


INVITE request for 

Non-CUG 

communication 


CUG without 
preference 


CUG communication 

(*1)(*3) 

IC: spec. CUG 


CUG 

communication (*1) 

(*3) 

IC: spec. CUG 


Return 403 
(Forbidden) 
response 


Return 403 
(Forbidden) 
response 


403 (Forbidden) 
response 


CUG+OAE 

without 
preference 


CUG communication 

ri)(*3) 

IC: spec. CUG 


CUG+OA (*2) (*3) 
IC: spec. CUG 


Return 403 
(Forbidden) 
response 


Non-CUG 
communication 


Return 403 
(Forbidden) 
response 


CUG+OAI 

without 

preference 


CUG+OA (*2) (*3) 
IC: spec. CUG 


CUG+OA (*2) (*3) 
IC: spec. CUG 


Non-CUG 
communication 


Non-CUG 
communication 


Non-CUG 
communication 


CUG with 
preference 


CUG communication 

ri)(*3) 

IC: spec. CUG 


CUG 

communication (*1) 

(*3) 

IC: spec. CUG 


CUG (*4) 
communication 
IC: pref. CUG 


403 (Forbidden) 
response 


CUG 

communication 
IC: pref. CUG (*4) 


CUG+OAE with 
preference 


CUG communication 

ri)(*3) 

IC: spec. CUG 


CUG+OA (*2) (*3) 
IC: spec. CUG 


CUG (*4) 
IC: pref. CUG 


Non-CUG 
communication 


CUG 

communication (*4) 
pref. CUG 


CUG+OAI with 
preference 


CUG+OA 
(*1)(*2)(*3) 
IC: spec. CUG 


CUG+OA 
(*2)(*3)(*1) 
IC: spec. CUG 


(*4) (*5) 


CUG+OA ri)(*4) 
IC: pref. CUG 


(*4) (*5) 


No CUG 


Return 403 
(Forbidden) 
response 


Return 403 
(Forbidden) 
response 


Return 403 
(Forbidden) 
response 


Return 403 
(Forbidden) 
response 


Non-CUG 
communication 


OAE Outgoing access, explicit request required. 

OAI Outgoing access, implicit outgoing access for all communications. 

IC Interlock code of the CUG selected. 

spec. CUG specific CUG indicated within the CUCIndex 

pref. CUG preferred CUG indicated by the user profile 

NOTE: As lA (incoming access) attribute of the calling user is of no concern for this validation check, CUG+OA/IA is 

equivalent to CUG+OA in this table. 
(*1 ) In case of OCB (outgoing communications barred) return 603 (Decline) response. 
(*2) In case of OCB within the CUG, the communication is interpreted as a non-CUG communication. An INVITE 

request without a cuglnterlockBinaryCode, networklndicator and cugCommunicationlndicator shall be sent 

towards the terminating user. 
(*3) In case the specified index does not match any of the registered indices, 403 (Forbidden) response 
(*4) In the case of OCB within the CUG, this combination is not allowed. 
(*5) Both 'Preferential CUG' and 'implicit' outgoing access options imply that no subscriber procedures are needed 

to invoke either option when placing a communication. When a user subscribes to both options, the network 

does not know which option the user is invoking, if no additional procedures are used when placing the 

communication. Then one of the following operations are recommended: 

a) if no information is given, the preferential CUG will be assumed, this shall be included in the INVITE request 
sent towards the terminating user. 

b) the network will route the communication with preferential CUG with outgoing access. The communication 
will therefore be connected if the terminating access is: 

- a member of preferential CUG; or 

- a member of another CUG with incoming access; or 

- a non-CUG user. 



When a vnd.etsi.cug+xml MIME body is included in the outgoing INVITE request the AS shall set the handling 
parameter in the Content-Disposition for this MIME body to "required" as described in RFC 5621 [7] if outgoing access 
is not allowed. 
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4.5.2.5 



Void 



4.5.2.6 



Void 



4.5.2.7 



Void 



4.5.2.8 



Void 



4.5.2.9 



Void 



4.5.2.1 Actions at the AS of the terminating user 

Table 4.5.2.10.1 : Handling of a CUG communication at the AS of the terminating user 



CUG 

cugCommunicati 

onlndicator in 

INVITE request 


CUG match check 


Class of terminating user 


CUG 


CUG+IA 


No CUG 


No ICB 


ICB 


No ICB 


ICB 


CUG with OA not 
allowed 


Match 


CUG call 


Sent 603 
(Decline) 
response 


CUG call 


Sent 603 
(Decline) 
response 


Sent 403 

(Forbidden) 

response 


No match 


Sent 403 (Forbidden) response 


Sent 403 (Forbidden) response 


CUG with OA 
allowed 


Match 


CUG call 


Sent 603 
(Decline) 
response 


CUG+OA 
call 


Non-CUG call 


Non-CUG call 


No match 


Sent 403 (Forbidden) response 


Non-CUG call 


Non-CUG 


- 


Sent 403 (Forbidden) response 


Non-CUG call 




lA Incoming access Non-CUG call 

OA Outgoing access 

ICB Incoming communications barred 

Match The interlock code in the received INVITE request matches one of the CUGs to which the user belongs. 

No match The interlock code does not match any of the CUGs to which the terminating user belongs. 

NOTE: As OA attribute of the terminating user is of no concern at the AS of the terminating User , CUG+OA class is 

equivalent to CUG, and CUG+IA class is equivalent to CUG+IA in this table. Subscription of preferential CUG by 

the terminating user is also of no concern in this table. 



In case of each successful CUG Check an INVITE request without a CUG xml MIME shall be sent towards the 
terminating user. Therefore the received CUG xml MIME shall be discarded. 



4.5.2.11 



Void 



4.5.2.12 Actions at the terminating UA 

Procedures according to 3GPP TS 24.229 [2] shall apply. 



4.6 



Interaction with other services 



4.6.1 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.2 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 
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4.6.3 Terminating Identification Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Originating Identification Presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.5 Originating Identification Restriction (OIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.6 Conference calling (CONF) 

When the communication involving the first conferee is added to the conference, then the conference shall assume the 
CUG of that communication. 

In order to add a subsequent communication to the conference, then the CUG of that communication shall be checked 
against the CUG of the conference. 

4.6.7 Communication Diversion Services (CDIV) 

4.6.7.1 Communication Forwarding Unconditional (CFU) 

CUG restrictions shall be checked and met for the communication between the originating party and the forwarding 
party. The information of a CUG applied by the IMS on the original communication shall be used for the 
communication forwarding and by this means CUG restrictions shall be checked and met for the communication 
between the originating party and the forwarded-to party. 

In the case of multiple forwarding, CUG restrictions between the originating party and the forwarding party have to be 
checked and met at each intermediate forwarding point. In addition, CUG restrictions between the originating party and 
forwarded-to party shall be met end-to-end. 

The outgoing communication barring information of the forwarding party shall not be used to determine whether the 
communication can be forwarded. 

The CUG information sent to the "forwarded-to" destination shall the same CUG information of the originating party 
that was sent from the originating network. 

4.6.7.2 Communication Forwarding Busy (CFB) 

See interactions with CFU in subclause 4.6.7.1. 

4.6.7.3 Call Forwarding No Reply (CFNR) 

See interactions with CFU in subclause 4.6.7.1. 

NOTE: CUG restrictions were checked and met for the communication between the originating party and the 
forwarding party when the communication was offered to the forwarding party. 

4.6.7.4 Communication Forwarding on Not Logged-in (CFNL) 

See interactions with CFU in subclause 4.6.7.1. 

4.6.7.5 Communication Forwarding on Subscriber Not Reachable (CFNRc). 

See interactions with CFU in subclause 4.6.7.1. 
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4.6.7.6 Communication Deflection (CD) 

The information of a CUG applied by the IMS on the original communication shall be used for the deflected part of the 
communication and by this means CUG restrictions shall be checked and met for the communication between the 
originating party and the deflected-to party. 

In the case of multiple deflections, CUG restrictions between the originating party and the deflecting party have to be 
checked and met at each intermediate deflecting point. In addition, CUG restrictions between the originating party and 
deflected-to party shall be met end-to-end. 

When a communication is deflected, a new check of the CUG restrictions between the originating party and the 
deflected-to party is made at the "deflected-to" destination. The CUG information sent to the 'deflected-to' destination is 
the same CUG information of the originating party that was sent from the originating network. 

The outgoing communication barring information of the deflecting party shall not be used to determine whether the 
communication can be deflected. 

NOTE: CUG restrictions were checked and met for the communication between the originating party and the 
deflecting party when the communication was offered to the deflecting party. 

4.6.8 Malicious Communication Identification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.9 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.1 Explicit Communication Transfer (ECT) 

The two communications shall use the same CUG for the transfer to be successful. 

NOTE: CUG restrictions between users will have been checked when the first communication is established. 
Similarly, CUG restrictions between users will have been checked when establishing the second 
communication. 

4.6.1 1 Closed User Group (CUG) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.12 Three-Party (3PTY) 

For the successful invocation of the three party service any CUG restrictions applied to one communication shall match 
with any CUG restrictions applied to the other communication. 

4.7 Interactions with other networks 

4.7.1 Void 

4.7.2 Void 

4.7.3 Void 
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Annex A (informative): 
Void 
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Annex B (informative): 
Change history 



Change history 
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TSG# 
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CR 
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Old 


New 


2007-11 










Publication as ETSI TS 183 054 




2.1.0 


2007-12 










Conversion to 3GPP TS 24.454 




2.1.1 


2007-12 










Technically identical copy as 3GPP TS 24.654 as basis for further 
development 




2.1.2 


2008-02 










Implemented CI -080094 




2.2.0 


2008-04 










Implemented CI -08081 2,C1 -080896, CI -081 1 00, CI -081 1 01 
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2.3.0 


2008-05 










Implemented CI -81 562, CI -81 837, CI -81 91 9 
Editorial: Change of Keywords, Change of title 
Incorporation of comments from ETSI Edit help 
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2008-05 


CT#40 


CP-080336 






Editorial changes done by MCC 


2.4.0 


2.4.1 


2008-06 


CT#40 
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2.4.1 


8.0.0 


2008-06 
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8.0.0 
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2008-09 


CT#41 
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8.0.1 


8.1.0 
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0004 




Removal of unused reference in TS 24.654 


8.1.0 


8.2.0 


2008-12 


CT#42 
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2 


Interaction between SIP and Ut based service configuration 


8.1.0 


8.2.0 
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Editorial cleanup by MCC 
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8.2.0 
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